<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Packet-level time synchronization</title>
<meta name="author" content="Miklos Maroti, Janos Sallai" />
<style type="text/css">

/*
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:date: $Date: 2009-02-03 23:07:32 $
:version: $Revision: 1.2 $
:copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.
*/
body {
  font-family: Times;
  font-size: 16px;
}

.first {
  margin-top: 0 ! important }

.last {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dd {
  margin-bottom: 0.5em }

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 0em 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1 {
  font-family: Arial, sans-serif;
  font-size: 20px;
}

h1.title {
 text-align: center;
 font-size: 32px;
}

h2 {
 font-size: 16px;
 font-family: Arial, sans-serif;
}

h2.subtitle {
  text-align: center }

h3 {
 font-size: 12px;
 font-family: Arial, sans-serif;
}

hr {
  width: 75% }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee;
  border-color: #000000;
  border-width: thin; 
  font-size: 14px
}

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.option-argument {
  font-style: italic }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

table {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.citation {
  border-left: solid thin gray ;
  padding-left: 0.5ex }

table.docinfo {
  margin: 2em 4em;
}

table.footnote {
  border-left: solid thin black ;
  padding-left: 0.5ex }

td, th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

th.docinfo-name, th.field-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap;
  }

h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
  font-size: 100% }

tt {}

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body>
<div class="document" id="packet-level-time-synchronization">
<h1 class="title">Packet-level time synchronization</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">TBA</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Draft</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">&gt; 2.1</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>Miklos Maroti, Janos Sallai</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">15-May-2008</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2008-06-17</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List &lt;tinyos-devel at mail.millennium.berkeley.edu&gt;</td>
</tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">This memo documents a part of TinyOS for the TinyOS Community, and requests
discussion and suggestions for improvements.  Distribution of this memo is
unlimited. This memo is in full compliance with TEP 1.</p>
</div>
<div class="section">
<h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This TEP describes a packet-level time synchronization mechanism that allows for
sending a time value along with the packet which is automatically converted from
the sender's local time to the receiver's local time by the communications
stack.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>Time of occurrence of events is often of interest in a sensor network.
Maintaining a synchronized UTC or a virtual global time in a sensor network may,
however, lead to significant communication overhead and may not always be
required by the application.</p>
<p>This TEP describes a packet-level time synchronization mechanism that allows for
sending a time value along with the packet which is automatically converted from
the sender's local time to the receiver's local time by the communications
stack. Packet-level time synchronization is limited to single-hop communication
and does not provide synchronized network time. It provides a simple yet
powerful abstraction, on top of which it is possible to implement higher-level
time synchronization services (e.g. FTSP <a class="footnote-reference" href="#id17" id="id1" name="id1">[6]</a>)in a platform-independent way.
Packet-level time synchronization is semantically equivalent to the ETA
primitives <a class="footnote-reference" href="#id12" id="id2" name="id2">[1]</a>.</p>
<p>The rest of this TEP specifies:</p>
<ul class="simple">
<li>Platform-independent packet-level time synchronization interfaces</li>
<li>How these interfaces are provided in the HIL</li>
<li>A guideline how each transceiver's HAL may implement the above interfaces</li>
</ul>
</div>
<div class="section">
<h1><a id="interface" name="interface">2. Interface</a></h1>
<p>Packet-level time synchronization is implemented by the communication stack and
is exposed through two interfaces, <tt class="docutils literal"><span class="pre">TimeSyncAMSend</span></tt> and <tt class="docutils literal"><span class="pre">TimeSyncPacket</span></tt>.</p>
<p>The <tt class="docutils literal"><span class="pre">TimeSyncAMSend</span></tt> interface allows for sending a time value (e.g. an event
timestamp) along with a message. It is parameterized by the precision and width
of the time value:</p>
<pre class="literal-block">
interface TimeSyncAMSend&lt;precision_tag, size_type&gt;
{
  command error_t send(am_addr_t addr, message_t* msg, uint8_t len, size_type event_time);
  command error_t cancel(message_t* msg);
  event void sendDone(message_t* msg, error_t error);
  command uint8_t maxPayloadLength();
  command void* getPayload(message_t* msg, uint8_t len);
}
</pre>
<p>The <tt class="docutils literal"><span class="pre">send</span></tt> command sends a regular message just like <tt class="docutils literal"><span class="pre">AMSend.send</span></tt> <a class="footnote-reference" href="#id13" id="id3" name="id3">[2]</a>, but
it also performs sender-receiver time synchronization. The <tt class="docutils literal"><span class="pre">event_time</span></tt>
parameter holds the time of some event as expressed in the local clock of the
sender. The receiver can obtain the time of this event (expressed in its own
local time) via the <tt class="docutils literal"><span class="pre">TimeSyncPacket</span></tt> interface.</p>
<p>The rest of the functionality is identical to that of the <tt class="docutils literal"><span class="pre">AMSend</span></tt> interface,
therefore its description is omitted here.  Please refer to <a class="footnote-reference" href="#id13" id="id4" name="id4">[2]</a> for details.</p>
<p>The <tt class="docutils literal"><span class="pre">TimeSyncPacket</span></tt> interface, parameterized by a precision tag and width,
allows for retrieving a time value that was sent along the received packet:</p>
<pre class="literal-block">
interface TimeSyncPacket&lt;precision_tag, size_type&gt;
{
        command bool isValid(message_t* msg);
        command size_type eventTime(message_t* msg);
}
</pre>
<p>The <tt class="docutils literal"><span class="pre">isValid</span></tt> command returns <tt class="docutils literal"><span class="pre">TRUE</span></tt> if the value returned by
<tt class="docutils literal"><span class="pre">eventTime</span></tt> can be trusted. Under certain circumstances the received packet
cannot be properly time stamped, so the sender-receiver synchronization cannot
be finished on the receiver side. In such case, this command returns <tt class="docutils literal"><span class="pre">FALSE</span></tt>.
This command MUST be called only on the receiver side and only for messages
transmitted via the TimeSyncAMSend interface.</p>
<p>The communications stack MUST guarantee that if the <tt class="docutils literal"><span class="pre">isValid</span></tt> command called
from within the <tt class="docutils literal"><span class="pre">receive</span></tt> event handler returns <tt class="docutils literal"><span class="pre">TRUE</span></tt>, then the value
returned by the <tt class="docutils literal"><span class="pre">eventTime</span></tt> command can be trusted. However, it might be
possible that the local clock overflowed more than once or that is was stopped
or reset since the packet was received, which causes the <tt class="docutils literal"><span class="pre">event_time</span></tt> to be
invalid. The <tt class="docutils literal"><span class="pre">isValid</span></tt> command MAY return <tt class="docutils literal"><span class="pre">TRUE</span></tt> in such situations, and it
is the responsibility of the user of the interface to ensure that the clock runs
freely from the time of message reception to the time when <tt class="docutils literal"><span class="pre">eventTime</span></tt> is
called. To avoid this issue, it is recommended that <tt class="docutils literal"><span class="pre">isValid</span></tt> and
<tt class="docutils literal"><span class="pre">eventTime</span></tt> are called from the <tt class="docutils literal"><span class="pre">receive</span></tt> event handler.</p>
<p>The <tt class="docutils literal"><span class="pre">eventTime</span></tt> command should be called by the receiver of a packet. The
time of the synchronization event is returned as expressed in the local clock of
the caller. This command MUST BE called only on the receiver side and only for
messages transmitted via the <tt class="docutils literal"><span class="pre">TimeSyncAMSend</span></tt> interface.</p>
</div>
<div class="section">
<h1><a id="hil-requirements" name="hil-requirements">3. HIL requirements</a></h1>
<p>The signature of the platform's ActiveMessageC <a class="footnote-reference" href="#id16" id="id5" name="id5">[5]</a> MUST include:</p>
<pre class="literal-block">
provides interface TimeSyncAMSend&lt;TMilli, uint32_t&gt;;
provides interface TimeSyncPacket&lt;TMilli, uint32_t&gt;;
</pre>
<p>where event times are given in the node's local time, which is available through
<tt class="docutils literal"><span class="pre">HILTimerMilliC.LocalTime</span></tt>.</p>
<p>The communications stack MAY support timestamp precisions and widths other than
<tt class="docutils literal"><span class="pre">TMilli</span></tt> and uint32_t, respectively. Also, alternative <tt class="docutils literal"><span class="pre">TimeSyncAMSend</span></tt> and
<tt class="docutils literal"><span class="pre">TimeSyncPacket</span></tt> implementations MAY use clock sources other than
<tt class="docutils literal"><span class="pre">HILTimerMilliC.LocalTime</span></tt>.</p>
</div>
<div class="section">
<h1><a id="implementation-guidelines" name="implementation-guidelines">4. Implementation guidelines</a></h1>
<p>Packet-level time synchronization employs the ETA primitives. In this TEP, only
the basics of the time synchronization mechanism are described, for details
please see <a class="footnote-reference" href="#id12" id="id6" name="id6">[1]</a>. This section presents two possible implementation approaches.
The first approach assumes that the payload of the packet is still mutable when
the transmission time of the packet (e.g. the timestamp of the SFD interrupt)
becomes available. The second approach avoids this assumption and uses the
packet timestamping functionality described in TEP <a class="footnote-reference" href="#id15" id="id7" name="id7">[4]</a> to implement packet-
level time synchronization.</p>
<div class="section">
<h2><a id="approach-1" name="approach-1">4.1 Approach #1</a></h2>
<p>Several transceivers allow for modifying the contents of a packet after packet
transmission is started. Packet-level time synchronization can be implemented
very efficiently on such platforms.</p>
<p>Transmitter's story</p>
<blockquote>
<ul class="simple">
<li>When the communications stack services a <tt class="docutils literal"><span class="pre">TimeSyncAMSend.send</span></tt> command called
with event timestamp <tt class="docutils literal"><span class="pre">t_e</span></tt>, it stores <tt class="docutils literal"><span class="pre">t_e</span></tt> (e.g. in a map with the pointer
of the message_t as key) and sets the designated timestamp field in the packet
payload to <tt class="docutils literal"><span class="pre">0x80000000</span></tt>.</li>
<li>When the packet starts being transmitted over the communication medium, a
corresponding hardware event is timestamped (e.g. an SFD interrupt). Let us
denote this transmission timestamp with <tt class="docutils literal"><span class="pre">t_tx</span></tt>. The difference of event
timestamp <tt class="docutils literal"><span class="pre">t_e</span></tt> and transmit timestamp <tt class="docutils literal"><span class="pre">t_tx</span></tt> is written into the
designated timestamp field in the payload of the packet (typically into the
footer, since the first few bytes might have been transmitted by this time).
That is, the information the packet contains at the instance when being sent
over the communications medium is the age of the event (i.e. how much time ago
the event had occurred).</li>
<li>If an error occurs with timestamping the transmission or with writing the
package payload after transmission has started, then the designated timestamp
field in the packet payload will contain <tt class="docutils literal"><span class="pre">0x80000000</span></tt>, indicating the error
to the receiver.</li>
</ul>
</blockquote>
<p>Receiver's story</p>
<blockquote>
<ul class="simple">
<li>The packet is timestamped with the receiver node's local clock at reception
(e.g. with the timestamp of the SFD interrupt). Let us denote the time of
reception with <tt class="docutils literal"><span class="pre">t_rx</span></tt>. The reception timestamp is stored in the metadata
structure of the <tt class="docutils literal"><span class="pre">message_t</span></tt> <a class="footnote-reference" href="#id16" id="id8" name="id8">[5]</a>.</li>
<li>When the event time is queried via the <tt class="docutils literal"><span class="pre">TimeSyncPacket</span></tt> interface, the
<tt class="docutils literal"><span class="pre">eventTime</span></tt> command returns the sum of the value stored in the designated
timestamp field in packet payload and the reception timestamp, i.e. <tt class="docutils literal"><span class="pre">e_t-</span>
<span class="pre">e_tx+e_rx</span></tt>. This value corresponds to the time of the event in the receiver's
local clock.</li>
<li>The <tt class="docutils literal"><span class="pre">TimeSyncPacket.isValid</span></tt> command returns <tt class="docutils literal"><span class="pre">FALSE</span></tt> if the time
value stored in the payload equals <tt class="docutils literal"><span class="pre">0x80000000</span></tt> or if the communications
stack failed to timestamp the reception of the packet. Otherwise <tt class="docutils literal"><span class="pre">TRUE</span></tt> is
returned, which indicates that the value returned by
<tt class="docutils literal"><span class="pre">TimeSyncPacket.eventTime</span></tt> can be trusted.</li>
</ul>
</blockquote>
</div>
<div class="section">
<h2><a id="approach-2" name="approach-2">4.1 Approach #2</a></h2>
<p>If a particular platform does not support changing the packet contents after the
synchronization event (start of transmission, SFD interrupt, etc.) had occured,
it is still possible to provide packet-level time synchronization functionality
at the cost of some communication overhead. Such an approach can rely on packet
timestamping TEP <a class="footnote-reference" href="#id15" id="id9" name="id9">[4]</a> to implement packet-level time synchronization.</p>
<p>Transmitter's story</p>
<blockquote>
<ul class="simple">
<li>When the communications stack services a <tt class="docutils literal"><span class="pre">TimeSyncAMSend.send</span></tt> command
called with event timestamp <tt class="docutils literal"><span class="pre">t_e</span></tt>, it stores <tt class="docutils literal"><span class="pre">t_e</span></tt> (e.g. in a map with the
pointer of the message_t as key) and sends the packet.</li>
<li>Transmission of the packet is timestamped using the packet timestamping TEP
<a class="footnote-reference" href="#id15" id="id10" name="id10">[4]</a> mechanism. Let us denote this transmission timestamp with <tt class="docutils literal"><span class="pre">t_tx</span></tt>. The
difference of event timestamp <tt class="docutils literal"><span class="pre">t_e</span></tt> and transmit timestamp <tt class="docutils literal"><span class="pre">t_tx</span></tt> is sent
in an auxilliary packet. That is, the information the auxulary packet contains
is the age of the event at the time when the initial packet was transmitted.</li>
</ul>
</blockquote>
<p>Receiver's story</p>
<blockquote>
<ul class="simple">
<li>The packet is timestamped with the receiver node's local clock at reception
(e.g. with the timestamp of the SFD interrupt). Let us denote the time of
reception with <tt class="docutils literal"><span class="pre">t_rx</span></tt>. The reception timestamp is stored in the metadata
structure of the <tt class="docutils literal"><span class="pre">message_t</span></tt> <a class="footnote-reference" href="#id16" id="id11" name="id11">[5]</a>.</li>
<li>When the auxilliary packet arrives, the time value it carries (<tt class="docutils literal"><span class="pre">t_e-t_tx</span></tt>,
the age of the event) is stored in a metadata field of the main packet. The
auxilliary packet is discarded, and the receive event is signalled with the
pointer to the main packet.</li>
<li>When the event time is queried via the <tt class="docutils literal"><span class="pre">TimeSyncPacket</span></tt> interface, the
<tt class="docutils literal"><span class="pre">eventTime</span></tt> command returns the sum of the value stored in the metadata (age
of the event) and the reception timestamp, i.e. <tt class="docutils literal"><span class="pre">e_t-</span> <span class="pre">e_tx+e_rx</span></tt>. This value
corresponds to the time of the event in the receiver's local clock.</li>
<li>The <tt class="docutils literal"><span class="pre">TimeSyncPacket.isValid</span></tt> command returns <tt class="docutils literal"><span class="pre">FALSE</span></tt> if the communications
stack failed to timestamp the reception of the packet. Otherwise <tt class="docutils literal"><span class="pre">TRUE</span></tt> is
returned, which indicates that the value returned by
<tt class="docutils literal"><span class="pre">TimeSyncPacket.eventTime</span></tt> can be trusted.</li>
</ul>
</blockquote>
</div>
<div class="section">
<h2><a id="reference-implementation" name="reference-implementation">5. Reference implementation</a></h2>
<p>A reference implementation of the packet-level time synchronization mechanism
described in this TEP can be found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/rf230</span></tt>.</p>
</div>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">6. Author's Address</a></h1>
<div class="line-block">
<div class="line">Miklos Maroti</div>
<div class="line">Janos Sallai</div>
<div class="line">Institute for Software Integrated Systems</div>
<div class="line">Vanderbilt University</div>
<div class="line">2015 Terrace Place</div>
<div class="line">Nashville, TN 37203</div>
<div class="line">phone: +1 (615) 343-7555</div>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">7. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id12" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id12">[1]</a></td><td><em>(<a class="fn-backref" href="#id2">1</a>, <a class="fn-backref" href="#id6">2</a>)</em> Kusy, B., Dutta, P., Levis, P., Maroti, M., Ledeczi, A., Culler, D., Elapsed Time on Arrival: A simple and versatile primitive for canonical time synchronization services. International Journal of Ad hoc and Ubiquitous Computing, Vol, 2, No. 1, 2006.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id13" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id13">[2]</a></td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> TEP 116: Packet protocols</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id14" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id14">[3]</a></td><td>TEP 102: Timers</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id15" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id15">[4]</a></td><td><em>(<a class="fn-backref" href="#id7">1</a>, <a class="fn-backref" href="#id9">2</a>, <a class="fn-backref" href="#id10">3</a>)</em> TEP TBA: Packet timestamping</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id16" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id16">[5]</a></td><td><em>(<a class="fn-backref" href="#id5">1</a>, <a class="fn-backref" href="#id8">2</a>, <a class="fn-backref" href="#id11">3</a>)</em> TEP 111: message_t</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id17" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1" name="id17">[6]</a></td><td>Maroti, M., Kusy, B., Simon, G., and Ledeczi, A. 2004. The flooding time synchronization protocol. In Proceedings of the 2nd international Conference on Embedded Networked Sensor Systems (Baltimore, MD, USA, November 03 - 05, 2004). ACM SenSys '04.</td></tr>
</tbody>
</table>
</div>
</div>
</body>
</html>
